fix(components): page wrapper filters DOM attributes through the shared whitelist - #7958

Fixes #7933

PageRenderer closed its DOM leak with a hand-maintained destructure list and
spread the remainder onto its wrapper div, under a comment telling the next
reader to keep that list aligned with PageSchema. The alignment is what failed:
React forwards an unknown lowercase attribute in silence and stringifies object
values, so a key the list did not name was not dropped — it was emitted.

Clause-2

no. No schema's accept/reject behaviour changes (BaseSchema.passthrough()
is untouched), no public surface widens, and no gate's scan population moves —
the five names this PR expires from the leak ledger stay in
COMPONENTS_PLAIN_TYPES, so they are still SWEPT, just no longer recorded as
leaking. What moves is a behaviour population, which the survey below
measures.

The mechanism, not a longer list

The set of keys an author may put on a node is unbounded; the set a widget may
put on an element is declared. A deny-list bounded by enumeration cannot be
finished — the objectui#4425 ruling — and toDomProps is the one executor it
promoted to @object-ui/core for exactly this. page.tsx was one of the last
faces still closing the leak with an enumeration of its own. This PR makes it
call the shared whitelist; it invents nothing.

style stays forwarded BY NAME (it is not on the element-agnostic whitelist,
so nothing else would deliver it), as does the data-obj-id / data-obj-type
designer channel.

Survey — the behaviour population this moves

Corpus: every statically-readable authored node in the repo whose type is one
of the five registry keys PageRenderer is registered under, from .json,
fenced json in .md/.mdx, and object literals in .ts/.tsx.

A static key list is not a leak measurement, so every key was then driven
through the real SchemaRenderer path and the wrapper's attributes read off the
rendered element, on all five registry keys:

Dropped: actions alloworgoverride anchors badge barekey canonicalkey
context createdefaults createderive createfields createschema
createseed data domain href interfaceconfig item label labelkey
listcolumns name pagename properties slots somerendererprop.

Kept, unchanged: class id aria-label data-obj-id data-obj-type
data-page-type data-canary.

Two findings the corpus scan alone would have missed:

• context is host-injected. app-shell's PageView.tsx adds a context
  bag to every page it renders, so context="[object Object]" was on the
  wrapper of every page the console showed — the leak never needed an unusual
  author to reach production.
• slots and label are declared spec keys that the hand list did not
  name, so a spec-conformant page leaked them.

Safety gate — is any leaked attribute consumed downstream as a DOM
attribute? No. Searched for CSS attribute selectors ([actions], [actions=,
…), getAttribute('KEY'), e2e locators, and snapshot pins over all 25 names.
Every hit was JS array-destructuring or a computed key ([canonicalKey]:), an
unrelated a[href] focus selector, or ASCII art. No snapshot pins the wrapper.
Nothing reads these as attributes, so the replacement is safe.

The nail

packages/components/src/__tests__/page-dom-leak-whitelist-7933.test.tsx — 10
cases, 2 per registry key.

Positive control. Restoring the hand-maintained destructure list turns the
pin red and it names itself, rather than reporting a generic assertion failure:

FAIL  packages/components/src/__tests__/page-dom-leak-whitelist-7933.test.tsx
      > type:'page' — an undeclared authored key never reaches the wrapper
- Expected                          + Received
  "illegitimateAttributes": []      "illegitimateAttributes": [
                                      "actions", "context", "label",
                                      "name", "pagename", "slots" ]
  "pin": "objectui#7933 — page wrapper DOM pass-through whitelist"
  "surface": "PageRenderer wrapper div[data-page-type] for registry key 'page'"

Restored by STATE, not by exit code: the worktree blob returned to
be8b9d332c1696554caf82e7bb95f6b69eb226b9, identical to the HEAD blob, with
git diff HEAD at 0 bytes and git status --short empty. The mutation was
confirmed on disk first (rawPageProps 0 to 2 occurrences, toDomProps(props)
1 to 0) so a no-op edit could not have been read as a passing control.

Negative control. Five more cases assert the attributes the wrapper genuinely
needs are still delivered — class, data-page-type, data-obj-id,
data-obj-type, style, id, role, tabindex, and the open data-* /
aria-* families. A whitelist is a dropping mechanism, so "the leak is gone" is
half a measurement; style in particular survives only because it is forwarded
by name, and nothing but this half is watching it. Writing it caught a real
fact: data-obj-id / data-obj-type are DERIVED by SchemaRenderer from the
node's id and type, not authored, so the pin asserts the values the pipeline
actually produces.

The coupled ledger expiry (second commit)

packages/app-shell/src/__tests__/widget-dom-leak-sweep.test.tsx carries a
two-way ratchet: a new leaked attribute fails it, and so does FIXING one, until
the row is deleted in the same change — "Rows leave this ledger by being
DELETED in the change that fixes them." With only the first commit the gate
read Tests 5 failed | 197 passed (202), found: [] against
ledgered: [14 attributes] on ui:app ui:home ui:page ui:record
ui:utility. The registry resolves ui:page and bare page to the same
registration, which is how the sweep reaches PageRenderer at all.

Causality was proven by ablation rather than assumed: with the pre-fix mechanism
restored the same gate is 202/202 green, so those five were this change's doing
and not a pre-existing red.

The second commit deletes exactly those five names from the targets list of
the BARE_SPREAD group in COMPONENTS_LEAK_GROUPS. The list goes 91 to 86
entries — five fewer, no more and no less. Nothing else in that file moves: no
structural change, no docstring edit, no new group, no other target touched. All
five remain in COMPONENTS_PLAIN_TYPES, so they are still swept on every run,
now expected to be clean.

Verification

All Vitest runs from the repo root (RUN v4.1.10 /home/user/objectui-issue-7933),
never a package cwd. Re-run after the final commit bdf78fc4c, at which
git diff HEAD is 0 bytes.

node scripts/check-changeset-presence.mjs re-run after the app-shell file
entered the diff (not carried over), verbatim:

3 source file(s) of 2 released package(s) changed, and this change declares 1 changeset(s): .changeset/spotty-pages-drop-leaks.md.

node scripts/check-changeset-no-major.mjs: No changeset declares a major bump.

https://claude.ai/code/session_01KbJQ1y1J12nZxYzFWhP8Q3